3GPP defines an IP Multimedia Subsystem and, more specifically, the IP Multimedia Core Network Subsystem to enable support for IP multimedia applications. For the sake of simplicity, and since the IP Multimedia Subsystem is defined by 3GPP as being access-independent, all references are made throughout this specification to the IP Multimedia Subsystem (hereinafter IMS).
According to 3GPP, a user may register into the IMS network or receive a terminating call to experience IMS services. To this end, such user must be given a subscription to the IMS.
A user with an IMS subscription is given one or more Private User Identities. An IMS Private user Identity (hereinafter IMPI) is assigned by the home network operator, and is used for Registration, that is, for Authorization and Authentication into the IMS network. A user may also have one or more Public User Identities. An IMS Public User identity (hereinafter IMPU) is used by any user as a user's identifier for communications with other users.
Generally speaking, any IMPU of an IMS subscription may be shared by more than one IMPI within the same IMS subscription. In particular, an IMPU may be shared amongst all the IMPI's of an IMS subscription as stated in 3GPP TS 23.228. This feature is called IMPU sharing, and such IMPU is generally known under 3GPP as a ‘shared IMPU’.
In this respect, FIG. 1 illustrates an exemplary IMS subscription in accordance with 3GPP, wherein “Public User Identity—3” and “Public User Identity—4” are both shared by all the IMPI's of the IMS subscription, namely “Private User Identity—1” and “Private User Identity—2”, and are thus both considered ‘shared IMPU's’.
On the one hand, an IMS subscriber may register into the IMS network with an IMPI/IMPU pair selected by the IMS subscriber amongst those IMPI's and IMPU's associated in the IMS subscription of the IMS subscriber. The IMS subscriber thus registers into the IMS with a ‘Register’ message of a Session Initiation Protocol (hereinafter SIP) as defined by 3GPP and including a selected IMPU/IMPI pair.
A conventional registration process includes the submission of a ‘SIP Register’ message from the IMS subscriber towards a so-called Proxy Call Session Control Function server (hereinafter P-CSCF), which forwards such message towards an Interrogating Call Session Control Function server (hereinafter I-CSCF) of the IMS network where the destination subscriber belongs. The I-CSCF is in charge of selecting an appropriate Serving Call Session Control Function server (hereinafter S-CSCF) for serving the IMS subscriber, and queries a Home Subscriber Server (hereinafter HSS) in charge of subscription data for subscribers of the IMS network where the IMS subscriber belongs to. Assuming that the IMS subscriber had not previously registered the IMPI/IMPU pair, the HSS returns the capabilities required for an S-CSCF to be assigned for serving the IMS subscriber. The I-CSCF receiving such capabilities selects an appropriate S-CSCF fulfilling the capabilities, and forwards the ‘SIP Register’ message with the IMPI/IMPU pair thereto. The S-CSCF receiving the ‘SIP Register’ message submits its own registration towards the HSS to indicate it has been assigned for serving the subscriber identified by the IMPI/IMPU pair. The HSS then changes the status of said IMPI and IMPU from ‘not registered’ to ‘registered’, stores a reference to the S-CSCF as being assigned for serving the IMS subscriber, and downloads a user profile associated to said IMPU towards the S-CSCF. The S-CSCF receiving the user profile for the IMS subscriber is now ready for serving the IMS subscriber.
On the other hand, a terminating call received in an IMS network of the destination subscriber does not include any IMPI but just a given IMPU of the destination subscriber selected by the call originating subscriber. Such given IMPU might have previously been registered, in which case it would be marked as ‘registered’ in the HSS; or not registered at all, in which case it would be marked as ‘not registered’ in the HSS; or not registered as a result of the registration process explained above but having received a previous terminating call, in which case it would be marked as ‘unregistered’ in the HSS
Conventionally, a terminating call is received at an I-CSCF of the IMS network where the destination subscriber belongs to and includes an IMPU identifying the destination IMS subscriber. Upon receipt of the terminating call, with an ‘Invite’ message of a Session Initiation Protocol (hereinafter SIP) as defined by 3GPP, a query is submitted from the I-CSCF towards the HSS in charge of subscription data for subscribers of the IMS network where the destination IMS subscriber belongs to. The HSS answers such query either with the required capabilities of an assignable S-CSCF (where the IMPU is ‘not registered’ and no S-CSCF is assigned to the IMPU), or with an identifier of a previously assigned S-CSCF (where the IMPU is in ‘registered’ or ‘unregistered’ state). Depending on the submission received, the I-CSCF either selects an assignable S-CSCF fulfilling the capabilities or newly assigns the previously assigned S-CSCF, and forwards the ‘SIP Invite’ message thereto. If such S-CSCF receiving the ‘SIP Invite’ message had already downloaded a user profile associated to said IMPU, the S-CSCF progresses the call in accordance with existing procedures. Otherwise, the S-CSCF receiving the ‘SIP Invite’ registers itself as been assigned for serving the IMS subscriber towards the HSS and includes the given IMPU addressed in the terminating call but no IMPI. The HSS, aware of being a terminating call, changes the status of the given IMPU from ‘not registered’ to ‘unregistered’ (unless the given IMPU was already in an ‘unregistered’ status as a result of a previous terminating call addressing such IMPU), stores a reference to the S-CSCF as being assigned for serving the IMS subscriber, and determines a user profile associated to the given IMPU to be downloaded towards the assigned S-CSCF. Apart from that, where the given IMPU is associated with only one single IMPI, the HSS may include this single IMPI to be downloaded towards the assigned S-CSCF.
However, where the given IMPU is a shared IMPU associated with all the IMPI's in the IMS subscription, the HSS cannot determine a single IMPI to built up an IMPI/IMPU pair related to the terminating call. The HSS can only follow the 3GPP technical specifications, whereby an arbitrary IMPI might be selected, or alternatively all the IMPI's of the IMS subscription being returned.
This approach is very inefficient since more granularity per IMPI basis is a continuous demand by operators of IMS networks, whereby other criteria than simply selecting an arbitrary IMPI or selecting all the IMPI's of the IMS subscription are taken into account where the given IMPU in a terminating call is a shared IMPU of the IMS subscription.